Map hostedtool.CodeInterpreter to the Anthropic code_execution tool and parse its result blocks - #637

Parity issue: stderr mapped to TextContent instead of ErrorContent

The upstream Python implementation (agent_framework_anthropic/_chat_client.py, case "code_execution_tool_result") maps stderr to Content.from_error(message=content_block.content.stderr), which produces an ErrorContent node. Here the Go implementation maps stderr to &message.TextContent{}. Callers that switch on content type (e.g., to distinguish diagnostic output from normal output) will behave differently across SDKs.

Suggestion: use &message.ErrorContent{Message: res.Stderr, ...} for stderr to match Python semantics. Similarly, error_code (line 339) maps to TextContent in Go but to Content.from_error() in Python — both should use ErrorContent.

Upstream reference: python/packages/anthropic/agent_framework_anthropic/_chat_client.py lines 1338–1356.

Parity note: code_execution tool-call input encoding differs from Python

The Python implementation (_chat_client.py, line 1252–1265) wraps the raw input block as Content.from_text(text=str(content_block.input)) — a plain TextContent containing the string representation of the input dict.

This Go implementation extracts the "code" key from the JSON payload and stores it base64-encoded as DataContent with media_type: text/x-python. While arguably more structured (and analogous to how OpenAI Responses surfaces it), this is a deliberate cross-SDK divergence: a consumer inspecting CodeInterpreterToolCallContent.Inputs[0] will receive a DataContent in Go but a TextContent in Python.

If this encoding difference is intentional, please document it (e.g., in a CHANGELOG entry or an inline comment noting the divergence from Python). If it should align, switch to &message.TextContent{Text: code} or align the Python side to emit DataContent.

Parity finding — missing anthropic-beta: code-execution-2025-08-25 header

The upstream Python implementation (python/packages/anthropic/agent_framework_anthropic/_chat_client.py) unconditionally includes code-execution-2025-08-25 in its BETA_FLAGS list and routes every request through client.beta.messages.create(), which sends the anthropic-beta header automatically. Without that header the Anthropic Messages API will not recognise the code_execution_20250825 tool or return server_tool_use/code_execution_tool_result blocks.

The Go provider uses the stable client.Messages.New() path and currently sends no anthropic-beta header when *hostedtool.CodeInterpreter is present. The request will likely be rejected or silently ignored by the API.

Upstream evidence: python/packages/anthropic/agent_framework_anthropic/_chat_client.py — BETA_FLAGS = ["mcp-client-2025-04-04", "code-execution-2025-08-25"] and _prepare_betas() merges that list into every request.

Suggested resolution: when *hostedtool.CodeInterpreter is appended to tools, also inject option.WithHeader("anthropic-beta", "code-execution-2025-08-25") into the Messages.New() / Messages.NewStreaming() call, or propagate it via MessageNewParams / an equivalent per-request option so the required beta flag reaches the API.

Parity finding — stderr and error_code mapped as TextContent rather than as an error signal

The upstream Python implementation (python/packages/anthropic/agent_framework_anthropic/_chat_client.py, case "code_execution_tool_result") distinguishes between output and error semantics:

• stderr → Content.from_error(message=..., ...) (error-typed content)
• BetaCodeExecutionToolResultError.error_code (the error-class result type) → Content.from_error(...)

The Go implementation maps both res.Stderr and res.ErrorCode to &message.TextContent{}, the same type used for stdout. Callers that inspect content type to detect execution failure will receive a plain text block instead of an error-typed content item, diverging from Python's semantic.

Note: res.ErrorCode in the Go SDK (CodeExecutionToolResultBlock.Content.ErrorCode) is a field on the success result type. Verify whether it carries the same semantics as Python's BetaCodeExecutionToolResultError; if so, it should also map to an error content type.

Upstream evidence: python/packages/anthropic/agent_framework_anthropic/_chat_client.py — Content.from_error(message=content_block.content.error_code, ...) for BetaCodeExecutionToolResultError, and Content.from_error(message=content_block.content.stderr, ...) for stderr.

Suggested resolution: Map res.Stderr to a message type carrying error semantics (or document the intentional divergence), and review whether res.ErrorCode represents an error-class result that should be surfaced as an error rather than plain text.

Parity finding — tool-call Inputs shape diverges from Python: DataContent (base64 + MIME) vs TextContent (raw string)

The upstream Python implementation (python/packages/anthropic/agent_framework_anthropic/_chat_client.py, the server_tool_use branch for code_execution) maps the tool-call input as:

inputs=[
    Content.from_text(
        text=str(content_block.input),
        raw_representation=content_block,
    )
]

This produces a plain TextContent with the raw string representation of the input dict.

The Go implementation extracts the code field from the input JSON and wraps it in a *message.DataContent with MediaType: "text/x-python" and base64-encoded Data. This is a meaningfully different shape:

• The Python Inputs[0] is a TextContent; the Go Inputs[0] is a DataContent.
• The Python value is the full input dict as a string (e.g. {"code": "..."}); the Go value is only the extracted code, base64-encoded.

Callers that pattern-match on Inputs[0] type or decode the content will see different types and encoding across SDKs.

Upstream evidence: python/packages/anthropic/agent_framework_anthropic/_chat_client.py — Content.from_text(text=str(content_block.input), ...) in the server_tool_use / code_execution branch.

Suggested resolution: Align the Inputs element with the Python shape (a TextContent containing the extracted code as plain text), or document this intentional divergence. The DataContent + text/x-python approach is reasonable as an enhancement, but should be explicitly discussed with the cross-SDK design owners.